arm64: fix boot stability issues #136
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fix deadlock conditions caused by logging in syscall handlers before preempt_disable. Timer interrupts firing while holding the logger lock caused context switches to hang when they tried to log. Changes: - syscall/handler.rs: Move preempt_disable() before any logging - aarch64/syscall_entry.rs: Same fix for ARM64 syscall path - ipc/fd.rs: Remove logging from FdTable::clone() which runs during fork() - memory/heap.rs: Document why heap must stay in TTBR1 (TTBR0 switches) - run-aarch64-boot-test-strict.sh: Only accept "breenix>" prompt (not kernel fallback mode) for honest test acceptance criteria Root cause: The RING3_CONFIRMED/EL0_CONFIRMED markers were logged before preempt_disable(), creating a window where timer interrupt + logger lock = deadlock. FdTable::clone() logging during fork() had the same issue. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Achieves 100% boot success rate (20/20 consecutive boots). Changes: - stack.rs: Remove all logging from ARM64 stack allocation path (timer interrupt + logger lock = deadlock during process creation) - linker.ld: Move __bss_start/__bss_end symbols outside NOLOAD section (symbols defined inside NOLOAD sections not visible to linker) - build.rs: Enable ARM64 linker script via cargo:rustc-link-arg Root cause analysis: 1. Data abort at 0xFFFF_0000_8000_0345 was a synchronous external abort (not translation fault) - MMU translated successfully but physical memory at 0x8000_0345 doesn't exist in QEMU virt (only 512MB-1GB RAM) 2. The bogus address came from memory corruption caused by logger deadlock during stack allocation 3. Timer interrupt firing while logger lock held + stack allocation trying to log = corrupted state leading to wild pointer The fix follows the same pattern as the syscall handler fixes: remove ALL logging from critical paths where interrupts may be enabled. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Update run-aarch64-boot-test-native.sh to only accept "breenix>" prompt, matching the strict test script. Previously accepted "Interactive Shell" which is the kernel fallback mode when userspace fails - this was a test gaming pattern that could mask regressions. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Fixes ARM64 boot stability by removing logging from critical paths that can cause deadlock when timer interrupts fire while holding the logger lock.
Key changes:
preempt_disable()(timer interrupt + logger lock = deadlock)FdTable::clone()which runs during fork()__bss_start/__bss_endsymbols outside NOLOAD section (symbols inside NOLOAD sections not visible to linker)Root cause: Logging in critical sections where interrupts are enabled creates a window where a timer interrupt can fire while the logger lock is held. Any context switch or interrupt handler trying to log then deadlocks, corrupting memory and causing wild pointer accesses (e.g., the data abort at physical address 0x8000_0345 which doesn't exist in QEMU's RAM).
Test plan
./docker/qemu/run-aarch64-boot-test-strict.shpasses with ~100% success rate (60 consecutive boots, all showed "breenix>" prompt)🤖 Generated with Claude Code